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Abstract 

The  inclusion  of  multiple  metrics  in  a  routing  computa¬ 
tion  is  called  policy-based  routing.  Previous  work  on  solu¬ 
tions  to  this  problem  have  focused  on  virtual-circuit-based 
solutions,  and  have  resulted  in  computationally  expensive 
algorithms.  This  paper  presents  a  number  of  advances  in 
the  provision  of  policy-based  routing  sendees  in  networks 
and  internetworks.  An  integrated  policy-based  routing  ar¬ 
chitecture  is  formulated  where  the  general  problem  is  de¬ 
composed  into  a  traffic  engineering  problem  of  computing 
routes  in  the  context  of  administrative  traffic  constraints, 
and  a  quality-of-sen’ice  ( QoS)  problem  of  computing  routes 
in  the  context  of  performance-related  path  constraints.  A 
family  of  routing  algorithms  are  presented  for  computing 
routes  in  the  context  of  these  constraints  which  achieve  new 
levels  of  computational  efficiency.  Lastly,  a  forwarding  ar¬ 
chitecture  is  presented  that  efficiently  supports  hop-by-hop 
forwarding  in  the  context  of  multiple  paths  to  each  destina¬ 
tion,  which  is  required  for  policy-based  routing. 


1.  Introduction 

The  architecture  of  today’s  Internet  is  based  on  the 
catenet  model  for  internetworking  [5,  6,  7].  The  two  basic 
components  of  a  catenet  are  networks  and  gateways,  where 
a  catenet  is  formed  by  the  interconnecting  of  networks  with 
gateways.  A  primary  goal  of  the  catenet  model,  and  there¬ 
fore  the  Internet  architecture,  was  to  encourage  the  develop¬ 
ment  and  integration  of  new  networking  technologies  into 
the  developing  catenets.  To  achieve  this  goal,  only  mini¬ 
mal  assumptions  were  made  of  networks  and  the  routing 
computation  by  the  catenet  model.  Networks  were  assumed 
to  support  the  attachment  of  a  number  of  computers,  trans¬ 
port  datagrams,  allow  switched  access  so  that  attached  com- 
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puters  could  “quickly”  send  datagrams  to  different  destina¬ 
tions,  and  provide  best-effort  delivery,  where  the  definition 
of  best-effort  allowed  datagrams  to  be  dropped  or  delivered 
out  of  order.  The  routing  computation  was  assumed  to  sup¬ 
port  a  single  forwarding  class  chosen  by  the  optimization  of 
a  single,  typically  delay -related  metric. 

This  best-effort  model  of  communication  has  proven  sur¬ 
prisingly  powerful.  Indeed,  much  of  the  success  of  the  In¬ 
ternet  architecture  can  be  attributed  to  this  inspired  de¬ 
sign  decision.  However,  largely  as  a  product  of  its  own 
success,  limitations  of  the  Internet  architecture  are  being 
encountered  as  it  is  applied  to  ever  more  demanding  ap¬ 
plications  [3],  Real-time  applications,  such  as  on-demand 
streaming,  audio  and  video  conferencing,  visualization,  and 
virtual  reality  require  varying  degrees  of  bandwidth,  delay, 
and  delay  jitter  commitments  from  the  network  infrastruc¬ 
ture,  which  render  shortest-path  routing  insufficient  and  call 
for  the  generalization  of  the  basic  routing  model  of  the  In¬ 
ternet  to  satisfy  constraints  on  multiple  metrics. 

Supporting  the  efficient  management  of  network  re¬ 
sources,  traffic  engineering  [2]  and  network  manage¬ 
ment  services  require  the  ability  to  control  the  allocation 
of  these  resources  among  network  flows  in  an  inter¬ 
net.  The  original  motivation  for  traffic  engineering  was 
the  need  by  IP  network  providers  of  the  ability  to  man¬ 
age  network  bandwidth  in  the  context  of  the  single -path 
routing  model  of  IP  networks  [19].  Lacking  such  capabil¬ 
ities,  the  tendency  of  single -path  routing  is  to  aggregate 
traffic  for  a  given  destination  onto  a  subset  of  the  pos¬ 
sible  paths  to  that  destination.  As  a  result,  networks 
frequently  experience  congestion  in  spite  of  the  availabil¬ 
ity  of  excess  capacity  for  the  offered  load. 

The  vulnerability  of  IP  services  to  basic  network  disclo¬ 
sure  and  denial  of  service  threats  is  another  result  of  the  lack 
of  traffic  engineering  capabilities  from  current  IP  mecha¬ 
nisms.  Excluding  computationally  expensive  firewall  mech¬ 
anisms,  IP  traffic  can  potentially  traverse  any  link  in  an  in¬ 
ternet.  Therefore,  the  disclosure  of  any  traffic  stream  and 
the  denial-of-service  attack  of  any  destination  in  an  internet 
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are  unavoidable  threats.  Fundamental  to  these  new  require¬ 
ments  is  the  ability  to  control  the  topology  used  to  forward 
traffic. 

The  metrics  used  in  routing  computations  are  assigned 
to  individual  links  in  the  network.  For  a  given  routing  appli¬ 
cation,  a  set  of  link  metrics  is  identified  for  use  in  comput¬ 
ing  the  path  metrics  used  in  the  routing  decision.  Link  met¬ 
rics  can  be  assigned  to  one  of  two  classes  based  on  how  they 
are  combined  into  path  metrics.  Concave  (or  minmax)  met¬ 
rics  are  link  metrics  for  which  the  minimum  (or  maximum) 
value  (called  the  bottleneck  value)  of  a  set  of  link  metrics 
defines  the  path  metric  of  a  path  composed  of  the  given 
set  of  links.  Examples  of  concave  metrics  include  residual 
bandwidth,  residual  buffer  space,  and  administrative  traffic 
constraints.  Additive  metrics  are  link  metrics  for  which  the 
sum  (or  product,  which  can  be  converted  to  a  sum  of  loga¬ 
rithms)  of  a  set  of  link  metrics  defines  the  path  metric  of  the 
path  composed  of  the  given  set  of  links.  Examples  of  ad¬ 
ditive  metrics  include  delay,  delay  jitter,  cost,  and  reliabil¬ 
ity. 

While,  in  general,  routing  with  multiple  constraints  is 
an  NP-complete  problem  [12,  13],  there  are  many  sub¬ 
classes  of  this  general  problem  that  have  been  shown  to  have 
polynomial-time  solutions.  For  example,  any  problem  in¬ 
volving  two  metrics  with  at  least  one  of  them  being  concave 
can  be  solved  in  polynomial-time  by  a  traditional  short¬ 
est  path  algorithm  on  the  graph  in  which  all  links  that  do 
not  comply  with  the  concave  constraints  have  been  pruned 
[9,  14,  20].  However,  even  for  this  case,  as  the  number  of 
constraints  becomes  exponential  in  the  size  of  the  graph, 
this  result  no  longer  holds. 

The  foundational  work  on  the  problem  of  computing 
routes  in  the  context  of  more  than  one  additive  metric  was 
done  by  Jaffe  [13],  who  defined  the  multiply-constrained 
path  problem  (MCP)  as  the  computation  of  routes  in  the 
context  of  two  additive  metrics.  He  presented  an  enhanced 
distributed  Bellman-Ford  algorithm  that  solved  this  prob¬ 
lem  with  time  complexity  of  0(n4b  log (nb)),  where  b  is  the 
largest  possible  metric  value. 

Since  Jaffe,  a  number  of  solutions  have  been  pro¬ 
posed  for  computing  exact  routes  in  the  context  of  mul¬ 
tiple  metrics  for  special  situations.  Wang  and  Crowcroft 
[20]  were  the  first  to  present  the  solution  to  comput¬ 
ing  routes  in  the  context  of  a  concave  and  an  additive  metric 
discussed  above.  Ma  and  Steenkist  [15]  presented  a  modi¬ 
fied  Bellman-Ford  algorithm  that  computes  paths  satisfying 
delay,  delay-jitter,  and  buffer  space  constraints  in  the  con¬ 
text  of  weighted-fair-queuing  scheduling  algorithms  in 
polynomial  time.  Cavendish  and  Gerla  [4]  presented  a  mod¬ 
ified  Bellman-Ford  algorithm  with  complexity  of  0(n3) 
which  computes  multi-constrained  paths  if  all  met¬ 
rics  of  paths  in  an  internet  are  either  non-decreasing  or 
non-increasing  as  a  function  of  the  hop  count. 


Recent  work  by  Siachalou  and  Georgiadis  [17] 
on  MCP  has  resulted  in  an  algorithm  with  complex¬ 
ity  0(nW  log (n))  (in  terms  defined  in  Section  3).  This 
algorithm  is  similar  to  the  QoS  algorithm  presented  in  Sec¬ 
tion  4  in  that  it  is  an  enhanced  version  of  the  Dijkstra 
algorithm  based  on  invariants  similar  to  those  underly¬ 
ing  the  algorithms  presented  in  Sections  3  and  4.  How¬ 
ever,  due  to  errors  in  the  algorithm  (not  discussed  further 
here  due  to  space  constraints),  it  does  not  compute  cor¬ 
rect  results. 

Several  other  algorithms  have  been  proposed  for  com¬ 
puting  approximate  solutions  to  the  QoS  routing  problem. 
Both  Jaffe  [13]  and  Chen  and  Nahrstedt  [9]  propose  algo¬ 
rithms  which  map  a  subset  of  the  metrics  comprising  a  link 
weight  to  a  reduced  range,  and  show  that  using  such  solu¬ 
tions  the  cost  of  a  policy-based  path  computation  can  be 
controlled  at  the  expense  of  the  accuracy  of  the  selected 
routes.  Similarly,  a  number  of  researchers  [13,  16]  have  pre¬ 
sented  algorithms  which  compute  routes  based  on  a  func¬ 
tion  of  the  multiple  metrics  comprising  a  link  weight.  These 
approximation  solutions  do  not  work  with  administrative 
traffic  constraints. 

In  this  paper,  the  inclusion  of  multiple  metrics  in  a 
routing  computation  is  called  policy-based  routing  [9,  20]. 
Policy-based  routing  supports  traffic  engineering  by  the 
computation  of  routes  in  the  context  of  administrative  con¬ 
straints  on  the  type  of  traffic  allowed  over  portions  of  an  in¬ 
ternet.  Analogously,  policy-based  routing  supports  quality- 
of-service  (QoS)  by  the  computation  of  routes  in  the  con¬ 
text  of  performance-related  constraints  on  the  paths  specific 
traffic  flows  are  allowed  to  use.  The  drawbacks  of  the  cur¬ 
rent  policy-based  routing  solutions  are  that  they  have  poor 
average  case  performance,  they  implement  inflexible  rout¬ 
ing  models,  and  solutions  for  computing  approximate  solu¬ 
tions  do  not  work  with  the  traffic  constraints  used  for  traffic 
engineering.  The  contributions  of  this  paper  are: 

•  The  first  unifying  approach  to  the  support  of  rout¬ 
ing  with  traffic  engineering  and  quality-of-service  con¬ 
straints. 

•  A  family  of  efficient  algorithms  for  computing 
routes  in  the  context  of  traffic-engineering  con¬ 
straints,  quality-of-service  constraints,  and  a  combina¬ 
tion  of  the  two,  which  achieve  new  levels  of  computa¬ 
tional  efficiency. 

•  A  forwarding  architecture  that  efficiently  supports 
hop-by-hop  forwarding  in  the  context  of  multi¬ 
ple  paths  to  each  destination. 

Sections  2,  3,  and  4  present  the  model  and  algorithms  for 
computing  optimal  routes  in  the  context  of  policy-based  link 
metrics.  The  algorithms  are  shown  to  be  correct  and  highly 
efficient. 


The  routing  model  used  by  the  Internet  architecture  is 
a  table-driven,  hop-by-hop  routing  model.  In  this  model, 
routers  learn  about  the  state  of  connectivity  in  an  internet  by 
exchanging  messages  with  each  other,  and  run  local  routing 
computations  whose  output  is  a  forwarding  table.  This  for¬ 
warding  table  is  used  by  the  router’s  forwarding  process  to 
make  per-packet  forwarding  decisions. 

In  contrast,  many  recent  policy-based  routing  propos¬ 
als  have  used  an  on-demand,  source-driven,  virtual-circuit- 
based  routing  model  where  routes  are  computed  on  receipt 
of  the  first  packet  of  a  flow,  and  forwarding  is  source  driven 
through  the  use  of  either  path  setup  or  source-routing  tech¬ 
niques.  There  are  several  weaknesses  to  this  model  com¬ 
pared  to  the  table-driven,  incremental  model.  First,  changes 
in  network  state  must  be  propagated  to  the  source,  and 
topology  change  requests  propagated  back  into  the  network 
to  adapt  to  changes  in  an  internet.  Second,  the  model  im¬ 
plements  centralized  routing  control  where  forwarding  state 
for  all  sources  at  a  given  point  in  the  network  is  maintained 
by  the  router  acting  for  those  sources.  Lastly,  information 
about  a  link  must  be  propagated  to  all  routers  in  an  inter¬ 
net.  As  a  result,  in  these  proposals,  routing  is  implemented 
as  a  centralized  routing  computation,  with  remote  control  of 
forwarding  state,  which  is  less  efficient,  responsive,  and  ro¬ 
bust  than  table-driven,  hop-by-hop  solutions. 

Section  5  presents  a  new  forwarding  architecture  that  ef¬ 
ficiently  supports  hop-by-hop  forwarding  in  the  context  of 
policy-based  routing  with  multiple  paths  to  each  destina¬ 
tion.  It  should  be  noted  that,  while  the  new  algorithms  for 
policy-based  routing  presented  in  this  paper  are  applicable 
to  any  routing  model,  a  primary  goal  of  their  design  has 
been  that  they  be  compatible  with  a  table-driven,  hop-by- 
hop  model. 

2.  A  Model  for  Policy-Based  Routing 

A  network  is  modeled  as  a  weighted  undirected  graph 
G  =  (TV,  E),  where  N  and  E  are  the  node  and  edge  sets, 
respectively.  By  convention,  the  size  of  these  sets  are  given 
by  n  =  |  N  |  and  m  =  |  E  \ .  Elements  of  E  are  unordered 
pairs  of  distinct  nodes  in  N.  A(i)  is  the  set  of  edges  ad¬ 
jacent  to  i  in  the  graph.  Each  link  (i,j)  £  E  is  assigned 
a  weight,  denoted  by  aty.  A  path  is  a  sequence  of  nodes 
<  x±,xz, . . .  ,Xd  >  such  that  (x»,Xj+i)  G  E  for  every 
i  =  1, 2, . . . ,  d  —  1,  and  all  nodes  in  the  path  are  distinct. 
The  weight  of  a  path  is  given  by  lop  =  Y^t=i  Wxix»+i  •  The 
nature  of  these  weights,  and  the  functions  used  to  combine 
these  link  weights  into  path  weights  are  specified  for  each 
algorithm. 

In  the  following,  we  propose  a  declarative  traffic  engi¬ 
neering  model  where  network  links  are  labeled  with  state¬ 
ments  declaring  what  the  desired  routing  policies  are  in  the 
form  of  constraints  of  the  traffic  allowed  on  each  link.  These 


constraints  take  the  form  of  link  expressions  in  a  boolean 
traffic  algebra  which  describe  the  traffic  allowed  on  a  link. 
New,  efficient  policy-based  routing  algorithms  then  com¬ 
pute  a  minimal  set  of  routes,  composed  of  a  path  expression 
and  a  next  hop,  for  each  destination  in  an  internet.  These  al¬ 
gorithms,  in  effect,  discover  the  optimal  set  of  forwarding 
classes  needed  at  a  given  source  in  the  internet  to  imple¬ 
ment  the  desired  policies.  These  path  expressions  are  then 
installed  in  the  appropriate  traffic  classifiers. 

The  traffic  algebra  is  a  boolean  algebra  used  to  define 
traffic  classes  in  a  flexible  and  efficient  way.  Specifically, 
it  is  composed  of  the  standard  boolean  operations  on  the 
set  {0,1},  where  p  primitive  propositions  (variables)  are 
true/false  statements  describing  characteristics  of  network 
traffic.  The  syntax  for  expressions  in  the  algebra  is  speci¬ 
fied  by  the  BNF  grammar: 

( P  "=  0  |  1  |  v\...vp  |  (-up)  |  (<p  A  ip)  \ 

(<P  V  <p)  |  (<p  ->  p) 

The  set  of  primitive  propositions,  indicated  by  v,t  in  the 
grammar,  can  be  defined  in  terms  of  any  globally  signifi¬ 
cant  attributes  of  the  ingress  router’s  state  that  can  be  ex¬ 
pressed  as  a  true/false  statement.  Link  expressions  identify 
the  traffic  classes  allowed  to  traverse  the  link,  and  are  de¬ 
noted  by  £ij  in  the  algorithms.  Path  expressions,  denoted  by 
ep  in  the  algorithms,  and  defined  as  ep  =  £Xlx2  A  sX2X3  A 
. .  -/\£Xd_lXd,  specify  the  set  of  traffic  classes  allowed  to  tra¬ 
verse  the  path.  There  is  a  maximum  of  2P  unique  sets  of  traf¬ 
fic  classes. 

The  SAT [p)  primitive  of  the  traffic  algebra  is  the  SAT¬ 
ISFIABILITY  problem  of  traditional  Boolean  algebra.  Sat¬ 
isfiability  must  be  tested  in  two  situations  by  the  algorithms 
presented  below  that  implement  traffic -engineering  compu¬ 
tations.  First,  an  extension  to  a  known  route  should  only  be 
considered  if  classes  of  traffic  exist  that  are  authorized  to 
use  both  the  path  represented  by  the  known  route  and  the 
link  used  to  extend  the  path  (at  line  15  in  Figure  2).  This 
is  true  iff  the  conjunction  of  these  expressions  is  satisfiable 
(i.e.  SAT(£i  A  £ij)).  Second,  given  that  classes  of  traffic 
exist  that  are  authorized  to  use  a  path  represented  by  a  new 
route,  the  algorithms  must  determine  whether  all  traffic  sup¬ 
ported  by  that  route  has  also  been  satisfied  by  other,  known 
shorter  routes  (not  shown  in  the  algorithms  presented  in  this 
paper).  This  is  true  iff  the  new  route’s  traffic  expression  im¬ 
plies  the  disjunction  of  the  traffic  expressions  for  all  known 
better  routes  (i.e.  (e*  — >  £,;i;  £;2,  ..)  is  valid ,  which  is  de¬ 
noted  by  (el  — >  Si)  in  the  algorithms).  Determining  if  an 
expression  is  valid  is  equivalent  to  determining  if  the  nega¬ 
tion  of  the  expression  is  unsatisfiable.  Therefore  expressions 
of  the  form  £i  — >  £2  are  equivalent  to  ->SAT(-\(e  1  — »  £2)) 
(or  -<SAT(ei  A  ->£2)). 

The  satisfiability  decision  performed  by  SAT{£)  is  the 
prototypical  NP-complete  problem  [12].  As  is  typical  with 


NP-complete  problems,  it  has  many  restricted  versions  that 
are  computable  in  polynomial  time.  An  analysis  of  strate¬ 
gies  for  defining  computationally  tractable  traffic  algebras 
is  beyond  the  scope  of  this  paper,  however  we  have  imple¬ 
mented  an  efficient,  restricted  solution  to  the  SAT  problem 
by  implementing  the  traffic  algebra  as  a  set  algebra  with  the 
set  operations  of  intersection,  union,  and  complement  on  the 
set  of  all  possible  forwarding  classes. 

The  routing  algorithms  presented  here  are  based  on  an 
enhanced  version  of  the  path  algebra  defined  by  Sobrinho 
[18],  which  supports  the  computation  of  a  set  of  routes  for  a 
given  destination  containing  the  “best”  set  of  routes  for  each 
destination.  Formally,  the  path  algebra  P  =  <  W,  ®,  A,  C 
,  0,  oo  >  is  defined  as  a  set  of  weights  W,  with  a  binary  op¬ 
erator  ©,  and  two  order  relations,  A  and  C,  defined  on  W. 
There  are  two  distinguished  weights  in  VV,  0  and  oo,  rep¬ 
resenting  the  least  and  absorptive  elements  of  VV,  respec¬ 
tively.  ©  is  the  original  path  composition  operator,  and  A 
is  the  original  total  ordering  from  [18].  ©  is  used  to  com¬ 
pute  path  weights  from  link  weights.  A  is  used  by  the  rout¬ 
ing  algorithm  to  build  the  forwarding  set,  starting  with  the 
minimal  element,  and  by  the  forwarding  process  to  select 
the  minimal  element  of  the  forwarding  set  whose  parame¬ 
ters  satisfy  a  given  QoS  request. 

A  new  relation  on  routes,  C,  is  added  to  the  algebra  and 
used  to  define  classes  of  comparable  routes  and  select  max¬ 
imal  elements  of  these  classes  for  inclusion  in  the  set  of  for¬ 
warding  entries  for  a  given  destination.  C  is  a  partial  order¬ 
ing  (reflexive,  anti-symmetric,  and  transitive)  with  the  fol¬ 
lowing,  additional  property: 

Property  1  (u>x  C  wy)  =>•  (uix  h  wv). 

A  route  rm  is  a  maximal  element  of  a  set  R  of  routes  in  a 
graph  if  the  only  element  r  €  R  where  rm  C  r  is  rm  it¬ 
self.  A  set  Rrn  of  routes  is  a  maximal  subset  of  R  if,  for  all 
r  €  R  either  r  cf  Rm,  or  r  £  Rm  and  for  all  s  £  R  —  {r}, 
r  J  s.  The  maximum  size  of  a  maximal  subset  of  routes  is 
the  smallest  range  of  the  components  of  the  weights  (for  the 
two  component  weights  considered  here).  An  example  path 
algebra  based  on  weights  composed  of  delay  and  cost  is  as 
follows: 

LOi  =  ( di,Ci ) 

0  =  (0,0) 

oo  =  (oo,oo) 

u>i  ©  u>j  =  (d  j  ©  dj ,  Ci  +  Cj ) 

u>i  A  u>j  =  ( di  <  dj)  V  {{di  =  dj)  A  (c»  <  Cj)) 

u>j  C  u>j  =  ( dj  <  di)  A  ( Cj  <  Ci) 

3.  Basic  Policy-Based  Routing  Algorithms 

The  notation  used  in  the  algorithms  presented  in  this 
paper  is  summarized  in  Table  1.  In  addition,  the  maxi- 


P  =  Queue  of  permanent  routes  to  all  nodes. 

Pn  =  Queue  of  permanent  routes  to  node  n. 

T  =  Heap  of  temporary  routes. 

Tn  =  Entry  in  T  for  node  n. 

Bn  =  Balanced  tree  of  routes  for  node  n. 

En  =  Summary  of  traffic  expression  for  all  routes 
_ in  Pn. _ 

Table  1.  Notation. 


Notation 

Description 

Queue 

Push(r ,  Q) 
Head(Q) 
Pop(Q) 
PopTail(Q ) 

Insert  record  r  at  tail  of  queue  Q  (0(1)) 
Return  record  at  head  of  queue  Q  (0(1)) 
Delete  record  at  head  of  queue  Q  (0(1)) 
Delete  record  at  tail  of  queue  Q  (0(1)) 

d-Heap 

Inserter ,  H ) 
IncreaseK  ey(r ,  r^) 

DecreaseKey(r,  r h) 

Min(H) 

DeleteMin(H) 

Delete(rh) 

Insert  record  r  in  heap  H  (0(logd(n))) 
Replace  record  in  heap  with  record  r  hav¬ 
ing  greater  key  value  ( 0(d\ogd(n ))) 

Replace  record  in  heap  with  record  r  hav¬ 
ing  lesser  key  value  (0(log(i(n))) 

Return  record  in  heap  H  with  smallest  key 
value  (0(1)) 

Delete  record  in  heap  H  with  smallest  key 
value  (0(dlogd(n))) 

Delete  record  r h  from  heap  (0(dlogd(n))) 
Balanced  Tree 

Insert(r ,  B) 

Insert  record  r  in  tree  B  (0(log(n))) 

Min(B) 

DeleteMin(B) 

Return  record  in  tree  B  with  smallest  key 
value  (0(log(n))) 

Delete  record  in  tree  B  with  smallest  key 
value  (0(log(n))) 

Table  2.  Operations  on  Data  Structures  [1]. 


mum  number  of  unique  truth  assignments  is  denoted  by 
A  =  2P,  the  maximum  number  of  unique  weights  by 
W  =  min  (range  of  weight  components),  and  the  max¬ 
imum  number  of  adjacent  neighbors  by  amax  =  max{| 
A(i)  ]  j  *  G  N}.  Table  2  defines  the  primitive  operations 
for  queues,  heaps,  and  balanced  trees  used  in  the  algorithms, 
and  gives  their  time  complexity  used  in  the  complexity  anal¬ 
ysis  of  the  algorithms. 

The  algorithms  presented  in  this  section  are  based  on  the 
data  structure  model  shown  in  Figure  1 .  In  this  structure,  a 
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Figure  1.  Basic  Data  Structures 


algorithm  Policy-Based-Dijkstra 

begin 

1  Push(<  s,  s,  0, 1  >,  Ps); 

2  for  each  {(s,j)  G  A(s)} 

3  Insert(<j,  s,uiaj ,  esj  >,  T); 

4  while  (|T|=0) 

begin 

5  <i,pi,u>i,£i>  <—  Min(T); 

6  DeleteMin(Bi)-, 

I  if  (|  Pi  |=0) 

8  then  DeleteMin(T ) 

9  els e  IncreaseKey(Min(Bi),  7)): 

10  £imp  <—  £*;  ptr  <—  Tail(Pi); 

II  while  ((etmp  +  0)  A  (ptr  A  0)) 

12  £tmp  <—  £tmp  A  =ptr.£;  ptr  <—  ptr.next; 

13  if  (Stmp  A  0) 

then  begin 

14  Push(<i,pi,uJi,£i>,  Pi); 

15  for  each  G  T(i)  |  SAT(£i  A  £ij)} 

begin 

16  * —  cjj  ©  bJiji  ~  j  * —  £ 'jj : 

17  if  (Tj  =  0) 

18  then  Insert(<j,i,ojj ,  £j  >,  T) 

19  else  if  (a) j  -<  Tj.u) 

20  then  DecreaseKey(<j,  i,  u>j,  £j  >,  T); 

21  Insert(<  j,  i,  uij,  £j  >,  Pj); 

end 

end 

end 

end 

Figure  2.  General-Policy-Based  Dijkstra. 


balanced  tree  (2?,)  is  maintained  for  each  node  in  the  graph 
to  hold  newly  discovered,  temporary  labeled  routes  for  that 
node.  The  heap  T  contains  the  lightest  weight  entry  from 
each  non-empty  Bi  (for  a  maximum  of  n  entries).  Lastly,  a 
queue.  Pi,  is  maintained  for  each  node  which  contains  the 
set  of  permanently  labeled  routes  discovered  by  the  algo¬ 
rithm,  in  the  order  in  which  they  are  discovered  (which  will 
be  in  increasing  weight).  The  general  flow  of  these  algo¬ 
rithms  will  be  to  take  the  minimum  entry  from  the  heap  T, 
compare  it  with  existing  routes  in  the  appropriate  Pi,  if  it  is 
incomparable  with  existing  routes  in  P,  it  is  pushed  onto  Pt, 
and  “relaxed”  routes  for  its  neighbors  are  added  to  the  ap¬ 
propriate  Bxs. 

The  correctness  of  these  algorithms  is  based  on  the  main¬ 
tenance  of  the  following  three  invariants:  for  all  routes 
I  £  P  and  J  £  B*,  I  P  J,  all  routes  to  a  given 

destination  i  in  P  are  incomparable  for  some  set  of  satisfy¬ 
ing  truth  assignments,  and  the  maximal  subset  of  routes  to  a 
given  destination  in  PUB*  represents  the  maximal  subset 
of  all  paths  to  j  using  nodes  with  routes  in  P.  Furthermore, 
these  invariants  are  maintained  by  the  following  two  con¬ 
straints  on  actions  performed  in  each  iteration  of  these  algo¬ 
rithms:  (1)  only  known-non-maximal  routes  are  deleted  or 
discarded,  and  (2)  only  the  smallest  known-maximal  route 
is  moved  to  P. 

Figure  2  presents  a  modified  Dijkstra  algorithm  that 


computes  an  optimal  set  of  routes  to  each  destination  sub¬ 
ject  to  multiple  general  (additive  or  concave)  path  met¬ 
rics,  in  the  presence  of  traffic  constraints  on  the  links. 
The  time  complexity  of  Policy-Based-Dijkstra  is  dominated 
by  the  loops  at  lines  4,  11,  and  15.  The  loop  at  line  4 
is  executed  nWA  times,  and  the  loop  at  line  15  m  IT  A 
times.  The  loop  at  line  11  scans  the  entries  in  Pi  to  ver¬ 
ify  a  new  route  is  best  for  some  truth  assignment.  For 
a  given  destination,  this  loop  is  executed  at  most  an  in¬ 
crementally  increasing  number  of  times,  starting  at  0  and 
growing  to  W A  —  1  (the  maximum  number  of  unique 
routes  to  a  given  destination)  for  a  total  of  Y^i~X  *  = 
(tt  A-i)vt  .4  tjmes  por  completeness,  the  statements  at  lines 
6  and  21  take  time  proportional  to  \og{amaxW  A)  for  a  to¬ 
tal  of  nW A\og(amaxW A)  and  inW A\og(amaxW A),  re¬ 
spectively;  and  those  in  lines  7-9  and  17-20  proportional 
to  logd(n)  for  a  total  of  nW  A  logd(n)  and  mW  A\ogd{n), 
respectively.  Therefore,  the  worst  case  time  complexity  of 
Policy-Based-Dijkstra,  dominated  by  the  loop  at  line  11,  is 
0(nW2A2). 

The  loop  at  line  11,  which  dominates  the  cost  of  Policy- 
Based-Dijkstra,  is  required  because  there  is  no  way  to  sum¬ 
marize  the  permanent  routes  for  a  destination.  However, 
for  the  traffic  engineering  and  QoS  variants  of  this  algo¬ 
rithm  (not  shown  here  due  to  space  constraints),  the  per¬ 
manent  routes  can  be  summarized  by  a  summary  traffic 
expression  (formed  by  the  disjunction  of  permanent  route 
path  expressions)  and  the  weight  of  the  last  route,  respec¬ 
tively.  Using  these  shortcuts,  the  complexity  of  the  traf¬ 
fic  engineering  and  QoS  algorithms  are  0(mAlog(A))  and 
0(mW  log(W)),  respectively. 

4.  Enhanced  Algorithms 

The  log  (A)  and  log(fU)  factors  in  the  complexity  of  the 
traffic  engineering  and  QoS  variants  of  the  Policy-Based- 
Dijkstra  algorithm  (respectively)  are  the  result  of  the  use  of 
a  balanced  tree  for  storing  the  temporarily  labeled  nodes  for 
a  given  destination.  This  section  presents  enhanced  versions 
of  these  algorithms  which  use  a  queue-based  data  structure 
for  this  purpose,  reducing  the  cost  of  managing  these  struc¬ 
tures  to  a  lower  order  term  in  the  time  complexity.  As  a  re¬ 
sult  the  runtime  cost  of  the  enhanced  algorithms  becomes 
dominated  by  logd(?r)  factors  from  the  manipulation  of  the 
T  heap. 

This  enhancement  is  based  on  the  property  that  routes 
to  a  given  node  with  the  same  predecessor  are  discovered 
in  strictly  increasing  (or  non-decreasing,  depending  on  the 
algorithm)  order.  This  property  is  a  result  of  the  fact  that 
routes  to  a  given  predecessor  will  be  discovered  in  strictly 
increasing  (non-decreasing)  order,  and  therefore  the  order 
of  discovery  of  routes  from  a  given  predecessor  to  one  of  its 
neighbors  will  have  the  same  property. 


Figure  3.  Enhanced  Data  Structures 


Based  on  this  insight,  the  data  structure  shown  in  Fig¬ 
ure  3  can  be  used  to  improve  the  performance  of  the  algo¬ 
rithms  presented  in  Section  3.  In  this  data  structure  the  bal¬ 
anced  trees  for  each  node  are  replaced  with  a  set  of  queues 
for  each  neighbor  of  the  node,  and  a  summary  heap  con¬ 
taining  the  head  of  each  neighbor  queue.  Exploiting  the  or¬ 
dering  property  of  these  queues,  the  algorithms  ensure  that 
each  node  head  Hi,  and  therefore  7),  contain  the  lightest 
route  in  the  link  queues  that  is  not  subsumed  by  the  routes 
in  Pi.  Due  to  space  constraints,  only  the  QoS  version  of 
these  algorithms  is  presented  here. 

Figure  1 1  presents  the  enhanced  version  of  the  TD-QoS- 
Dijkstra  algorithm.  Similar  to  the  basic  algorithms,  the  cor¬ 
rectness  of  these  algorithms  is  based  on  the  invariants  and 
constraints  presented  in  Section  3.  Specifically,  as  detailed 
in  the  comments  from  that  section,  constraints  1  and  2  are 
maintained  by  the  DeleteTMinf)  and  AddCandidatei)  func¬ 
tions,  and,  based  on  this,  the  Dijkstra  iteration  over  the  nth 
best  route  in  the  main  body  of  the  algorithm  maintains  the 
invariants. 

The  runtime  complexity  of  the  TD-QoS-Dijkstra  algo¬ 
rithm  is  dominated  by  the  loops  at  lines  6  and  10.  The  loop 
at  line  6  is  executed  at  most  once  for  each  incomparable 
path  to  each  node  in  the  graph  for  a  total  of  nW  times.  The 
loop  at  line  10  is  executed  at  most  once  for  each  distinct  in¬ 
stance  of  an  edge  in  the  graph,  for  a  total  of  mW  times.  The 
most  costly  operation  in  the  loop  at  line  6  is  the  Delete T- 
Min()  call  at  line  9.  In  the  DeleteTMin()  routine,  the  loop 
at  line  7  will  be  executed,  in  total,  at  most  once  per  neigh¬ 
bor  for  each  forwarding  class  for  a  total  of  amaxW,  and  the 
cost  per  call  of  the  heap  operations  at  lines  13  and  14  is 
d  log£)(?i).  Therefore,  the  total  worst-case  cost  of  the  call  at 
line  8  of  the  main  algorithm  is  nW  \ogd(n)  +  amaxW.  In 
the  AddCandidatei)  routine,  the  runtime  complexity  is  dom¬ 
inated  by  the  heap  operations  at  lines  5,  20,  and  23,  which 
cost  logd(n)  each,  for  a  total  cost  of  the  call  to  AddCan- 
didatef)  at  line  12  of  the  main  algorithm  of  mW\ogd(n). 
Therefore,  the  worst-case  time  complexity  of  the  enhanced 
TD-QoS-Dijkstra  algorithm  is  0{mW  log(n)). 

Figures  4  and  5  present  the  results  of  experiments  run  us¬ 
ing  the  TD-QoS-Dijkstra  algorithm.  The  experiments  were 
run  on  a  1GHz  Intel  Pentium  3  based  system.  The  algo- 
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Figure  4.  Enhanced  Runtime(Size) 
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Figure  5.  Enhanced  Space(Size) 


rithms  were  implemented  using  the  C++  Standard  Template 
Library  (STL)  and  the  Boost  Graph  Library.  Each  test  in¬ 
volved  running  the  algorithm  on  ten  random  weight 
assignments  to  ten  randomly  generated  graphs  (gen¬ 
erated  using  the  GT-ITM  package  [21]).  For  each  test 
the  worst  case  measurements  are  graphed.  The  met¬ 
rics  were  generated  using  the  “Cost  2”  scheme  from  [17] 
where  the  delay  component  is  randomly  selected  in  the 
range  1  ..Max Metric,  and  the  cost  component  is  com¬ 
puted  as  cost  =  a(MaxMetric  —  delay),  where  cr  is  a 
random  integer  in  the  range  1..5;  this  scheme  was  cho¬ 
sen  as  it  proved  to  result  in  the  most  challenging  com¬ 
putations  from  a  number  of  different  schemes  consid¬ 
ered.  The  QoS  routing  problem  was  used  for  these  tests  as 
it  was  easiest  to  generate  meaningful  random  metric  as¬ 
signments  for.  Space  overhead  was  measured  in  terms  of 
the  maximum  number  of  entries  stored  in  the  B*  struc¬ 
tures. 

Tests  were  run  for  performance  (both  runtime  and  space) 
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Figure  6.  Compare  Runtime(Size) 
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Figure  7.  Compare  Space(Size) 


as  a  function  of  graph  size,  average  degree  of  the  graph,  and 
the  maximum  link  metric  value.  Due  to  space  constraints, 
only  the  graphs  for  size  are  shown  here.  Also,  since  the 
maximum  metric  was  shown  to  have  little  impact  on  per¬ 
formance,  only  results  for  tests  with  a  maximum  metric  of 
1000  are  presented  here.  Figures  4  and  5  present  the  re¬ 
sults,  showing  that,  while  costs  increase  with  both  graph 
size  and  average  degree,  both  the  magnitude  and  rate  of 
growth  are  surprisingly  tame  for  what  are  fundamentally 
non-polynomial  algorithms.  While  runtime  grows  to  ap¬ 
proximately  2  seconds  for  the  largest  problems,  for  graphs 
smaller  than  500  nodes  with  an  average  degree  of  8  (well  be¬ 
yond  the  scale  supportable  by  current  Internet  routing  pro¬ 
tocols)  the  runtime  is  at  most  a  few  hundred  milliseconds, 
and  the  growth  rate  is  barely  beyond  linear  in  this  range  of 
parameters.  Similarly,  the  worst-case  space  utilization  stays 
below  30,000  entries  (consuming  less  than  10MB  of  mem¬ 
ory)  with  similar  growth  rates.  Figures  6  and  7  compare  the 
performance  of  the  basic  QoS  (not  presented  in  this  paper). 


enhanced  QoS,  and  traditional  (single  path)  Dijkstra  algo¬ 
rithms. 

5.  Hop-by-Hop  Policy-Based  Routing 

The  policy-based  routing  algorithms  presented  in  Sec¬ 
tions  3  and  4  compute  multiple  routes  to  the  same  des¬ 
tination  to  satisfy  the  policy  requirements  of  an  internet. 
Such  routes  are  not  supported  by  current,  host-address- 
based  packet  forwarding  mechanisms  that  only  allow  one 
route  per  destination.  The  solution  to  this  problem  is  to  use 
label-swapping  technology  (e.g.,  MPLS  [10])  as  a  gener¬ 
alized  forwarding  mechanism  that  replaces  IP  addresses  as 
the  names  for  network  attachment  points  in  the  route  bind¬ 
ing  function  with  arbitrary  labels  which  can  be  defined  by 
the  routing  protocol  to  represent  any  policy/destination  pair 
for  which  a  route  has  been  computed. 

A  significant  innovation  of  the  policy-based  routing  ar¬ 
chitecture  presented  here  is  the  combination  of  a  table- 
driven,  hop-by-hop  routing  model  with  label-swap  forward¬ 
ing  mechanisms.  Traditionally,  label-swap  forwarding  has 
only  been  seen  as  an  appropriate  match  with  an  on-demand, 
source-driven  routing  model.  Indeed,  to  a  large  extent,  the 
virtual-circuit  nature  of  these  previous  solutions  has  been 
attributed  to  their  use  of  label-swap  forwarding. 

Contrary  to  this  view,  the  position  taken  here  is  that  host 
addresses  and  labels  are  largely  equivalent  alternatives  for 
representing  forwarding  state,  and  that  the  virtual-circuit 
nature  of  prior  architectures  derives  from  their  use  of  a 
source-driven  forwarding  model.  The  primary  conceptual 
difference  between  address  and  label-swap  forwarding  is 
that  label-swap  forwarding  provides  a  clean  separation  of 
the  control  and  forwarding  planes  [19]  within  the  network 
layer,  where  address-based  forwarding  ties  the  two  planes 
together.  This  separation  provides  what  might  be  called  a 
topological  anonymity  of  the  forwarding  plane  that  is  criti¬ 
cal  to  the  implementation  of  policy-based  routes. 

Chandranmenon  and  Varghese  [8]  present  a  similar  no¬ 
tion,  which  they  call  threaded  indices ,  where  neighboring 
routers  share  the  indexes  into  their  routing  tables  for  spe¬ 
cific  routes  which  are  then  included  in  forwarded  packets 
to  allow  rapid  forwarding  table  lookups.  In  addition  they 
present  a  modified  Bellman-Ford  algorithm  that  exchanges 
these  labels  among  neighbors.  Our  solution  generalizes  the 
threaded  index  concept  to  use  generic  labels  (with  no  di¬ 
rect  forwarding  table  semantics),  uses  these  labels  to  repre¬ 
sent  routing  policies  computed  by  the  routing  protocols,  and 
defines  a  family  of  routing  protocols  to  exchange  local  la¬ 
bels  among  neighbors. 

As  illustrated  in  Figure  8,  label-swap  forwarding  can  be 
used  in  the  context  of  traditional  address-based  forwarding. 
In  this  example  the  forwarding  table  is  referenced  for  both 
traffic  classification  (through  the  “address  prefix”  field),  and 
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Figure  8.  Label-Swapping  with  Addresses 
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Figure  9.  Label-Swapping  with  Policies 


for  label-swap  forwarding  (through  the  “local  label”  field). 
The  benefit  of  this  mechanism  for  traffic  forwarding  is  it  can 
be  generalized  to  handle  policy-based  forwarding. 

For  example,  label-swap  forwarding  can  be  used  to  im¬ 
plement  traffic  engineering  via  the  assignment  of  traffic  to 
administrative  classes  which  are  used  to  select  different 
paths  for  traffic  to  the  same  destination  depending  on  the 
labeling  of  links  in  the  network  with  administrative  class 
sets.  Figure  9  shows  the  traffic  classification  and  forward¬ 
ing  state  for  a  small  network  with  four  nodes  and  the  two 
administrative  classes  A  and  B.  The  benefits  of  this  archi¬ 
tecture  are  that  it  is  based  on  forwarding  state  that  is  agnos¬ 
tic  to  the  definition  of  forwarding  classes,  allowing  the  data 
forwarding  plane  to  remain  simple  yet  general;  and  it  con¬ 
centrates  the  path  computation  functions  in  the  routing  pro¬ 
tocol,  which  is  the  least  time  critical,  and  most  flexible  com¬ 
ponent  of  the  network  layer. 

The  resulting  routing  architecture  can  be  seen  as  analo¬ 
gous  to  the  Reduced  Instruction  Set  Computer  (RISC)  pro¬ 
cessor  architecture  in  which  researchers  shifted  much  of  the 
intelligence  for  managing  the  use  of  processor  resources  to 
the  compilers  that  were  able  to  bring  a  higher-level  perspec¬ 
tive  to  the  task,  thus  allowing  much  more  efficient  use  of  the 
physical  resources,  as  well  as  freeing  the  hardware  design¬ 
ers  to  focus  on  performance  issues  of  much  simpler  proces¬ 
sor  architectures.  Similarly,  the  communications  architec¬ 
ture  proposed  here  requires  a  shift  in  intelligence  for  cus¬ 
tomized  (i.e.  policy-based)  path  composition  to  the  routing 
protocols  and  frees  the  network  layer  to  focus  solely  on  hop- 
by-hop  forwarding  issues,  adding  degrees  of  freedom  to  the 
network  hardware  engineering  problem  that,  hopefully,  al¬ 
low  for  significant  advances  in  the  performance  and  effec¬ 
tiveness  of  network  infrastructure. 

In  this  architecture,  the  role  of  the  routing  protocol  takes 


on  new  significance.  The  routing  protocols  used  in  most  of 
today’s  computer  networks  are  based  on  shortest-path  al¬ 
gorithms  that  can  be  classified  as  distance-vector  or  link- 
state.  Distance-vector  protocols  work  by  propagating  up¬ 
dates  giving  the  distance  to  a  destination  to  neighboring 
routers  whose  routing  tables  may  change  as  a  result  of  the 
update.  Link-state  protocols  work  by  flooding  updates  de¬ 
scribing  the  state  of  links  in  the  network  to  all  routers  in 
the  network.  Recently,  a  hybrid  class  of  protocols,  called 
link- vector  [11],  has  been  defined  that  works  by  propagat¬ 
ing  link-state  updates  only  to  routers  whose  routing  tables 
may  change  as  a  result  of  the  update. 

The  enhancement  of  traditional  unicast  routing  systems 
with  the  policy-based  routing  technology  presented  above  is 
straight-forward.  The  routing  protocol  must  be  enhanced  to 
carry  the  additional  link  metrics  required  to  implement  the 
desired  policies.  This  requires  the  use  of  either  a  link-state 
or  link-vector  routing  protocol  that  exchanges  information 
describing  link  state.  Note,  however,  that  for  a  system  de¬ 
pending  on  on-demand  routing  computations  a  link-state, 
complete  topology  protocol  is  required  to  ensure  an  ingress 
router  has  the  information  it  needs  to  compute  an  optimal 
route.  In  contrast,  hop-by-hop  based  routing  systems  can 
work  with  link-vector,  partial  topology  protocols  as  each 
routing  process  is  ensured  of  learning  from  its  neighbors 
of  all  links  composing  optimal  routes  to  all  destinations  in 
the  internet. 

Forwarding  state  must  be  enhanced  to  include  local  and 
next  hop  label  information  in  addition  to  the  destination  and 
next  hop  information  existing  in  traditional  forwarding  ta¬ 
bles.  Traffic  classifiers  must  be  placed  at  the  edge  of  an  in¬ 
ternet,  where  “edge”  is  defined  to  be  any  point  from  which 
traffic  can  be  injected  into  the  internet.  Since  each  router 
represents  a  potential  traffic  source  (for  CLI  and  network 


Figure  10.  Traffic  Flow  in  Policy-Enabled 
Router 


management  traffic),  this  effectively  means  a  traffic  clas¬ 
sification  component  must  be  present  in  each  router.  As 
illustrated  in  Figure  10,  the  resulting  traffic  flow  require¬ 
ments  are  that  all  non-labeled  traffic  (sourced  either  from 
a  router  itself,  or  from  a  directly  connected  host  or  non¬ 
labeling  router)  must  be  passed  through  the  traffic  classi¬ 
fier  first,  and  all  labeled  traffic  (sourced  either  from  the  traf¬ 
fic  classifier  or  a  directly  connected  labeling  router)  must  be 
passed  to  the  label-swap  forwarding  process. 

6.  Conclusions 

This  paper  presents  a  family  of  routing  algorithms  that 
efficiently  compute  routes  in  the  context  of  traffic  and  per¬ 
formance  constraints.  The  enhanced  TD-TE-Dijkstra  algo¬ 
rithm  is  the  most  efficient  algorithm  available  for  comput¬ 
ing  routes  that  satisfy  traffic  engineering  requirements,  and 
Policy-Based-Dijkstra  is  the  first  algorithm  for  computing 
routes  that  simultaneously  satisfy  traffic  engineering  and 
quality-of-service  requirements.  A  traffic  algebra  was  de¬ 
fined  to  formalize  the  notion  of  traffic  constraints,  and  a 
set-based  model  was  identified  for  efficiently  implement¬ 
ing  restricted  but  useful  traffic  engineering  policies.  Lastly, 
a  forwarding  architecture  was  defined  that  efficiently  imple¬ 
ments  multiple  paths  per  destination  required  for  hop-by- 
hop  policy-based  routing  using  label-swap-based  forward¬ 
ing. 
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algorithm  TD-QoS-Dijkstra 
begin 

1  Push(<s,s,  0>,  Ps); 

2  for  each  {(s,i)  G  A(s)} 

begin 

3  Push(<j,s,  ojsj>,  Q? ); 

4  Insert(<j,  s,ui3j  >,  Hj ); 

5  Insert(<j,  s,uisj  >,  T); 

end; 

6  while  ( |  T  |  >  0) 

begin 

7  <i,p,u>  <—  Min(T); 

B  Push{<  i,p,  u  >,  P;); 

9  DeleteTMinQ; 

10  for  each  {(i,  j)  G  A(i)} 

begin 

1  1  CUj  < —  id  (F  CUjj  ; 

12  AddCandidate(<  j,  i,  oJi  >); 

end 

end 

end 

function  QoS-DeleteTMin() 

//  Delete  minimum  entry  from  T  and  restore  invariants: 
//  Constraint  1  -  only  deletes  routes  (line  9)  that  are 
//  C  another  route. 

//  Constraint  2  -  loop  at  line  7  ensures  new  Tj  g 
//  new  Tail(Pi). 

begin 

1  <i,p,u>><—  Min(T); 

2  Pop(Of); 

3  if  (|Qf  |  >  0) 

4  then  IncreaseKey(Head(Qt’),  H?) 

5  else  DeleteMin(Hi); 

6  if  (|  PPi  |  >  0) 

then  begin 

//  Find  smallest  route  in  link  queues  that  is  not 
//  C  the  deleted  route. 

7  for  each  {(*,  k)  G  A(i)  |  (|  |  >  0)  A 

(Head(Q^).LO  C  cu)} 

begin 

B  while  ((|  |  >  0)  A  (Head(Q*).uj  C  u>)) 

9  PopiQk); 

10  if  (IQ?  I  >0) 

11  then  IncreaseKey(Head(Q^),  Ht) 

12  else  Delete(H^); 

end 

13  if  (I  PPi  |  >  0) 

then  IncreaseKey(Min(Hi),  Tj);  return; 
end 

14  DeleteMin(T ); 

end 


function  QoS-AddCandidate(<i,  p,  u>i  >) 

//  Add  new  route  to  appropriate  Q  and  restore  invariants: 

//  Constraint  1  —  only  drops  known  comparable  routes 
//  (lines  1,  10,  15,  and  24). 

//  Constraint  2  -  ensures  Mm(iJj)  A  (and  therefore  C7) 
//  all  routes  in  Q*  queues. 

begin 

1  if  (u>j  t  Tail(Pi).uj)  then  return; 

2  if  (|  Hi  |  =  0) 

then  begin 

3  Push(<i,p, uJi>,  Qf); 

4  Insert(<i,p,u>i>,  Hi); 

5  Insert{<  i,p,  u>i  >,  T); 

6  return; 
end 

7  <i,k,u. >m  >  <—  Min(Hi); 

8  if  (u^TTt  A  cUj) 

then 

9  if  (cUj  I  UJm) 

10  then  return; 

11  else  begin // ((o>j  JC  wm)  A  (wm  d  <«>«)) 

12  if  ( I  Qi  1=0) 

13  then  Insert(<  i,  p,  LUi  >,  Hi) 

14  else  if  (cui  □  Tail(Q^).cj) 

15  then  return; 

16  Push(<i,p,cji> ,  Q^); 

end 

else  //  cjj  -<  cum;  since  wi  >-  it  must  be 

//  true  that  |  Q ?  \  =  0. 

17  if  (c Qi  2  u;m) 

then  begin 

18  Push(<i,p,u)i>,  Q?); 

19  Insert(<i,p,uji> ,  iT^); 

//  Following  replaces  <i,k,  ujm  >. 

20  DecreaseKey(<i,p,LUi> ,  T^); 

end 

else  begin  //  (u^  □  cum) 

21  Push(<i,p,cui> ,  Q^); 

//  Following  replaces  <i,k,  ujm  >. 

22  DecreaseKey(<i,p,uJi>,  H^)\ 

23  DecreaseKey(<i,p,cui>,  T^); 

24  PMQi); 

25  if  (IQ?  I  >  0) 

26  then  Insert(Head(Q^),  Hi); 
end 

end 


Figure  11.  Enhanced  QoS  Dijkstra. 


